Systems and methods for pre-authorizing image studies

ABSTRACT

Methods and systems for pre-authorizing image studies. One method includes identifying an order for an imaging procedure requiring insurance pre-authorization, displaying the order to a first user through a user interface remotely accessible over a network connection, and receiving an assignment of the order to a second user from the first user. The method also includes displaying the order to the second user through the user interface, displaying a plurality of tasks for obtaining the insurance pre-authorization for the order to the second user through the user interface, wherein one of the plurality of tasks includes receiving a pre-authorization code for the order, and tracking, with the server, completion of each of the plurality of tasks by the second user through the user interface. The method also includes providing information regarding the completion of each of the plurality of tasks to the first user through the user interface.

RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application No.61/973,728 filed Apr. 1, 2014, the entire content of which isincorporated by reference herein.

FIELD

Embodiments of the present invention relate to methods and systems formanaging image studies within the medical industry.

BACKGROUND

When medical images are collected as part of an imaging procedure, theimages (referred to as an image study) are provided to a radiologist orother “reading physician” for review. The radiologist generates a reportcontaining the radiologist's findings based on review of the images.Traditionally, the findings of the report are faxed to the physician whoordered the imaging procedure. The fax includes only the text-basedfindings and not the images.

SUMMARY

In some situations, the ordering physician may want to see the imagesassociated with the report (e.g., to verify the findings or betterunderstand the meaning of the findings). The images, however, may bestored in a picture archiving and communication system (“PACS”) that mayor may not be readily accessible to the physician. Also, given the sizeof the images and the fact that the physician does not always want toreview the images, it is impractical to send the images to the physicianwith the report.

Therefore, embodiments of the invention provide systems and methods forconnecting an ordering physician with completed image reports and accessto images and related reports. Embodiments of the invention also providesystems and methods for connecting an ordering physician with an imagingprovider for placing an order for an imaging procedure. In addition,embodiments of the invention provide systems and methods for trackingthe status of an order (e.g., whether an order is scheduled, complete,undergoing a pre-authorization process, etc.) and generating reportsregarding orders and/or reports. Furthermore, embodiments of theinvention provide systems and methods for managing a pre-authorizationprocess for an order.

One embodiment of the invention includes at least one server that sitsbetween a report source (e.g., a radiology information system) and areport destination (e.g., an ordering physician's electronic medicalrecord (“EMR”) system). The server routes reports from the report sourceto the report destination. In some embodiments, the server routes thereport using a third-party network, such as a clinical messagingnetwork. The server can access a directory to identify how to route aparticular report to a particular ordering physician. The server alsoembeds a link in a routed report. The ordering physician can click onthe link to access a set of images associated with the report. Forexample, when an ordering physician (or other individual obtaining thereport with the link) clicks the link, the ordering physician accessesthe server via a browser application, the server identifies the imageset associated with the link, the server identifies where the image setis stored, and the server automatically transfers the ordering physicianto an image viewer where he or she can access the stored image set. Insome embodiments, the server also authenticates the ordering physicianbefore transferring the ordering physician to the image viewer. In someembodiments, the server also allows a user to place an order of animaging procedure. Furthermore, in some embodiments, the server allows auser to track and/or perform a pre-authorization process for an order.

For example, one embodiment of the invention provides a method ofmanaging an image study. The method includes receiving, with a server, acompleted report for the image study from a report source, establishing,with the server, a unique identifier for a set of images associated withthe completed report and stored in an image repository accessiblethrough an image viewer, storing, with the server, the unique identifierand an identifier of the image viewer in an image directory, andautomatically, with the server, creating a link associated with thecompleted report, the link based on the unique identifier. The methodalso includes identifying, with the server, a report destination for thecompleted report, and transmitting, with the server, the completedreport and the link to the report destination. In addition, the methodincludes, when a recipient selects the link, automatically, with theserver, identifying the image viewer based on the image directory, andautomatically, with the server, providing the recipient with access tothe image viewer.

Another embodiment of the invention provides a system for managing animage study. The system includes a server configured to communicate witha report source over at least one network connection. The server isconfigured to receive a completed report for the image study from thereport source, establish a unique identifier for a set of imagesassociated with the completed report and stored in an image repositoryaccessible through an image viewer, store the unique identifier and anidentifier of the image viewer in an image directory, and automaticallycreate a link associated with the completed report, the link based onthe unique identifier. The server is also configured to identify areport destination for the completed report and transmit the completedreport and the link to the report destination. In addition, when arecipient selects the link, the server is configured to automaticallyidentify the image viewer based on the image directory automaticallyprovide the recipient with access to the image viewer.

Yet another embodiment of the invention provides a method of managing animage study. The method includes receiving, with a server, orderinformation for an imaging procedure from a referring physician througha user interface remotely accessible over a network connection, andautomatically, with the server, routing the order information to areport source. The method also includes receiving, with the server,order status information from the report source, and making, with theserver, the order status information available to the referringphysician through the user interface. The method further includesreceiving, with the server, a completed report for the imaging procedurefrom the report source, making, with the server, the completed reportavailable to the referring physician through the user interface, andmaking, with the server, a set of images associated with the completedreport available to the referring physician.

Still another embodiment of the invention provides a system for managingan image study. The server is configured to communicate with a reportsource and includes a portal providing access to user interfacesaccessible over at least one network connection. The server is alsoconfigured to receive order information for an imaging procedure from areferring physician through the portal and automatically route the orderinformation to the report source. In addition, the server is configuredto receive order status information from the report source and make theorder status information available to the referring physician throughthe portal. Furthermore, the server is configured to receive a completedreport for the imaging procedure from the report source, make thecompleted report available to the referring physician through the userinterface, and make a set of images associated with the completed reportavailable to the referring physician.

A further embodiment of the invention provides a method of managing animage study. The method includes identifying, with a server, an orderfor an imaging procedure requiring insurance pre-authorization,displaying, with the server, the order to a first user through a userinterface remotely accessible over a network connection, and receiving,with the server, an assignment of the order to a second user from thefirst user. The method also includes displaying, with the server, theorder to the second user through the user interface, displaying, withthe server, a plurality of tasks for obtaining the insurancepre-authorization for the order to the second user through the userinterface, wherein one of the plurality of tasks includes receiving apre-authorization code for the order, and tracking, with the server,completion of each of the plurality of tasks by the second user throughthe user interface. In addition, the method includes providing, with theserver, information regarding the completion of each of the plurality oftasks to the first user through the user interface.

Another embodiment of the invention provides a system for managing animage study. The system includes a server configured to communicate witha report source and includes a portal providing access to userinterfaces accessible over at least one network connection. The serveris also configured to identify an order for an imaging procedurerequiring insurance pre-authorization, display the order to a first userthrough the portal, and receive an assignment of the order to a seconduser from the first user through the portal. The server is alsoconfigured to display the order to the second user through the portal,display a plurality of tasks for obtaining the insurancepre-authorization for the order to the second user through the portal,wherein one of the plurality of tasks includes receiving apre-authorization code, and track completion of each of the plurality oftasks by the second user through the portal. In addition, the server isconfigured to provide, through the portal, information regarding thecompletion of each of the plurality of tasks to the first user.

Other aspects of the invention will become apparent by consideration ofthe detailed description and accompanying drawings and appendices.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A schematically illustrates a system for routing image reportsfrom a report source to a report destination.

FIG. 1B schematically illustrates a routing server included in thesystem of FIG. 1A.

FIG. 1C schematically illustrates a method of routing a completed reportfrom a report source to a report destination using the system of FIG. 1A

FIG. 2 is a screen shot illustrating a user interface, provided by thereport source included in the system of FIG. 1A, for manuallytransmitting a completed image report from the report source to therouting server included in the system of FIG. 1A.

FIG. 3 is a screen shot illustrating a user interface, provided by thereport source included in the system of FIG. 1A, for tracking completedimage reports transmitted by the report source.

FIG. 4 is a screen shot illustrating a report received message generatedby the report destination included in the system of FIG. 1A.

FIGS. 5 and 6 are a completed image report provided to the reportdestination included in the system of FIG. 1A.

FIG. 7 schematically illustrates a method of providing a recipient of acompleted report access to an associated image study using the system ofFIG. 1A.

FIG. 8 schematically illustrates another method for providing arecipient of a completed report access to an associated image studyusing the system of FIG. 1A.

FIG. 9 schematically illustrates yet another method for providing arecipient of a completed report access to an associated image studyusing the system of FIG. 1A.

FIG. 10 is a screen shot illustrating a user interface, provided by therouting server included in the system of FIG. 1A, for prompting arecipient for credentials for accessing an image study.

FIG. 11 schematically illustrates still another method for providing arecipient of a completed report access to an associated image studyusing the system of FIG. 1A.

FIG. 12 is a screen shot illustrating a user interface for displaying animage study.

FIG. 13 is a screen shot illustrating a user interface, provided by therouting server included in the system of FIG. 1A, for providingstatistics of reports handled by the routing server.

FIG. 14 is a screen shot illustrating a user interface, provided by therouting server included in the system of FIG. 1A, for allowing a user toquery for details regarding one or more reports handled by the routingserver.

FIG. 15 is a screen shot illustrating a user interface, provided by therouting server included in the system of FIG. 1A, displaying a timelinereport for the routing server.

FIG. 16 is a screen shot illustrating a user interface, provided by therouting server included in the system of FIG. 1A, displaying a usagereport for the routing server.

FIG. 17 schematically illustrates a system for routing orders forimaging procedures.

FIGS. 18-23 are screen shots illustrating a user interface, provided bythe routing server included in the system of FIG. 17, for obtainingorder information.

FIGS. 24 and 25 are screen shots illustrating a user interface, providedby the routing server included in the system of FIG. 17, for providingorder status information.

FIG. 26 is a screen shot illustrating a user interface for performing apre-authorization process.

FIG. 27 is a screen shot illustrating a user interface for obtaining apre-authorization code as part of a pre-authorization process.

FIG. 28 is a screen shot illustrating a user interface for assigning anorder requiring pre-authorizations to a user.

DETAILED DESCRIPTION

Before any embodiments of the invention are explained in detail, it isto be understood that the invention is not limited in its application tothe details of construction and the arrangement of components set forthin the following description or illustrated in the accompanyingdrawings. The invention is capable of other embodiments and of beingpracticed or of being carried out in various ways.

Also, it is to be understood that the phraseology and terminology usedherein is for the purpose of description and should not be regarded aslimiting. The use of “including,” “comprising” or “having” andvariations thereof herein is meant to encompass the items listedthereafter and equivalents thereof as well as additional items. Also,electronic communications and notifications may be performed using anyknown means including secure email, direct connections, wiredconnections, wireless connections, etc. It should also be noted that aplurality of hardware- and software-based devices, as well as aplurality of different structural components may be utilized toimplement the invention. Furthermore, and as described in subsequentparagraphs, the specific configurations illustrated in the drawings areintended to exemplify embodiments of the invention, it being understoodthat other alternative configurations are possible.

It should also be noted that embodiments of the invention may includehardware, software, and electronic components or modules that, forpurposes of discussion, may be illustrated and described as if themajority of the components were implemented solely in hardware. However,one of ordinary skill in the art, and based on a reading of thisdetailed description, would recognize that, in at least one embodiment,the electronic based aspects of the invention may be implemented insoftware (e.g., stored on non-transitory computer-readable medium)executable by one or more processing units. As such, and by way ofexample, “electronic devices,” “computers,” “computing devices,”“controllers,” “control devices,” or “control modules” described in thepresent specification can include one or more processing units, one ormore computer-readable medium modules, one or more input/outputinterfaces, and various connections (e.g., a system bus) connecting thecomponents.

Report Routing

FIG. 1A illustrates a system 100 for communicating completed imagereports from a report source 102 to a report destination 104. In someembodiments, the report source 102 includes a radiology informationsystem (“RIS”) operated by an imaging provider. In other embodiments,the report source 102 can include a picture archiving and communicationsystem (“PACS”), an electronic medical record (“EMR”) system, adictation system, a cloud storage system, a hospital information system(“HIS”), etc.

The report source 102 stores image reports. An image report includesfindings by a radiologist based on a set of images (i.e., an imagestudy) generating during an imaging procedure. The image studies aregenerally stored in a separate image repository 106, such as anon-premise picture archiving and communication system (“PACS”) or acloud storage environment. In some embodiments, the image repository 106can be operated by the entity that operates the report source (e.g., animaging provider). However, in other embodiments, the image repository106 can be operated by a different entity. Also, in some embodiments,the image repository 106 can be included in the report source 102.

An image viewer 107 is associated with the image repository 106, whichallows users to access stored images through a user interface remotelyaccessible over a network connection, such as a web page accessible overthe Internet through a browser application. For example, the imageviewer 107 can include a web server that authenticates users accessingthe web server over the Internet through a browser application and, whenauthenticated, allows users to access and view images stored in theassociated image repository 106. In some embodiments, the image viewer107 is a zero-footprint image viewer that only requires a browserapplication to access and view images. In other embodiments, however,the image viewer 107 can include a dedicated interface or connectionbetween the image repository and the routing server 108 described below.It should be understood that, in some embodiments, the report source 102stores image studies to more than one image repository 106. Also, insome embodiments, the image viewer 107 is provided as part of the imagerepository 106, as compared to a separate device as illustrated in FIG.1A.

The report destination 104 can include a system associated with arecipient of a completed report, such as the physician initiallyordering the imaging procedure (i.e., the “ordering physician”). In someembodiments, the report destination 104 includes an EMR systemaccessible to the recipient. However, in other embodiments, the reportdestination 104 includes an HIS, an email server, a cloud storageenvironment, etc.

The system 100 also includes a central hub or routing server 108. Asillustrated in FIG. 1B, the server 108 includes one or more processingunits 108 a, one or more computer-readable memory modules 108 b, and oneor more input/output interfaces 108 c. The memory modules 108 b caninclude non-transitory memory, such as random access memory and/orread-only memory. The processing units 108 a can include amicroprocessor configured to execute instructions stored in the memorymodules 108 b. The memory modules 108 b can also store data used withand generated by execution of the instructions. The input/outputinterfaces 108 c allow the server 108 to communicate with externaldevices, including one or more wired or wireless networks 112 (e.g., theInternet, a clinical messaging network, a local area network, etc.). Theserver 108 can use the networks 112 to communicate with the reportsource 102, the report destination 104, and the image viewer 107 and, insome embodiments, uses different networks 112 to communicate with eachdevice. However, in some embodiments, the server 108 can be configuredto have a dedicated interface or connection to one or more devices, suchas the report source 102 and/or the image viewer 107.

It should be understood that in some embodiments, the server 108includes additional components than those illustrated in FIG. 1B. Itshould also be understood that, in some embodiments, the functionalityprovided by the server 108 as described below can be distributed amongmultiple servers. In addition, it should be understood that althoughonly a single report source 102, report destination 104, and imageviewer 107 are illustrated in FIG. 1A, the server 108 can be configuredto communicate with multiple different report sources 102, reportdestinations 104, and image viewers 107.

As illustrated in FIG. 1A, the server 108 can also include anetwork-based user interface portal 114 that allows a user (e.g., areferring physician, a radiologist, etc.) to interact with the server108. For example, the portal 114 can provide access to user interfacesaccessible over the Internet using a browser application. It should beunderstood that the portal 114 can be provided by the server 108 or aseparate device. Also, it should be understood that the user interfacesdescribed herein as being provided by the server 108 can be provided bythe portal 114.

As illustrated in FIG. 1C, when an image report is completed, the reportsource 102 routes the completed report to the server 108. The reportsource 102 can be configured to automatically route a completed reportto the server 108. Alternatively or in addition, the report source 102can be configured to allow a user to manually initiate transfer of thereport. For example, FIG. 2 illustrates a user interface 200 provided bythe report source 102. As illustrated in FIG. 2, the user interface 200allows a user to specify one or more recipients for a completed report(e.g., the ordering physician) using a “Recipient” input mechanism 202.The user interface 200 also allows a user to specify a distributionmethod for the report using a “Distribution Method” input mechanism 204.For example, a user can use the “Distribution Method” input mechanism204 to select an identifier of the routing server 108 (e.g., “iConnectNetwork”) when the server 108 is going to route or distribute thecompleted report. In some embodiments, rather than selecting the routingserver 108, a user can use the “Distribution Method” input mechanism 204to specify an alternative delivery method, such as fax transmission or amail delivery (e.g., performed directly by the report source 102). Asillustrated in FIG. 2, a user can select a “Complete” selectionmechanism 206 to manually initiate transmission of the report. In someembodiments, although the report source 102 transmits a completed reportto the server 108, the report source 102 retains a copy of eachcompleted report.

As illustrated in FIG. 1C, the report source 102 also transmits a uniqueidentifier for the image study associated with the completed report(stored in the image repository 106). In some embodiments, the uniqueidentifier includes an accession number assigned to the image study. Itshould be understood that, in some embodiments, the report source 102transmits the unique identifier within the completed report transmittedto the server 108 rather than as a separate transmission. Also, itshould be understood that the unique identifier provided by the reportsource 102 can include one or more pieces of identifying information forthe image study and associated report, such as an accession number, areport identifier, a report source identifier, a patient identifier, animage repository identifier, etc.

In some embodiments, the report source 102 tracks distributed completedreports. For example, as illustrated in FIG. 3, the report source 102can provide a user interface 300 that displays a list of reportstransmitted from the report source 102. A user can use the interface 300to identify what reports were transmitted and how each report wastransmitted (e.g., to the routing server 108, via fax, etc.). Asillustrated in FIG. 3, the interface 300 can also specify a reportstatus, such as whether a report was successfully delivered. Inparticular, the interface 300 can indicate whether a report wassuccessfully transmitted to the routing server 108 and/or the associatedrecipient (i.e., the report destination 104).

The server 108 uses information in the received report, the uniqueidentifier, or other information transmitted from the report source 102(e.g., a recipient selected by the user using the interface 200illustrated in FIG. 2) to identify one or more recipients for thecompleted report (e.g., the ordering physician and, optionally, otherphysicians or specialists). For example, in some embodiments, acompleted report includes an identifier of one or more recipients (e.g.,a unique identifier, a name, an office or location, or a combinationthereof). Also, in some embodiments, as described below, the server 108can store original order information associated with the completedreport, and the order information can include a list of one or morerecipients. Accordingly, in these situations, the server 108 can match areceived report to the corresponding order information (e.g., by anorder number) to identify one or more recipients for the completedreport.

After identifying one or more recipients for a completed report, theserver 108 accesses a recipient directory to identify how to route thereport to each recipient. The recipient directory can be stored on theserver 108 or on a separate device accessible to the server 108. Therecipient directory can specify, for each of a plurality of recipients,a method for delivering a report to the recipient. In particular, thedirectory can specify that a completed report should be faxed or mailedto a particular recipient and can provide a fax number or a mailingaddress of the recipient. Alternatively, the recipient directory canspecify that a completed report should be electronically delivered to aparticular recipient. For example, the recipient directory can specifythat a completed report for a specific recipient should be delivered toa report destination 104 (e.g., an EMR system) associated with therecipient that is accessible over a network managed by a healthcareprovider organization (e.g., Athenahealth, Allscripts, etc.) or anetwork managed by a third-party organization (e.g., Surescripts thatprovides a clinical messaging network for managing and routing messages,such as prescription-related messages). Accordingly, in thesesituations, the recipient directory can specify an identifier of thereport destination 104 and an identifier of the network through whichthe report destination 104 is accessible. In some embodiments, thesenetworks use direct messaging to securely (e.g., HIPAA-compliant andencrypted using private and public security keys, passwords, andcredentials) transmit the report to a report destination 104, such as arecipient's EMR system or other device with a direct messaging address.In some embodiments, the recipient directory can also specify that acompleted report for a particular recipient should be sent as anattachment to an email message and can provide an email address.

In some embodiments, the recipient directory can also specify multipleways to route a completed report to a particular recipient and,optionally, a hierarchy for the different routing options. For example,the recipient directory can specify that electronic delivery should beinitially attempted for a particular recipient. However, the recipientdirectory can specify that a fax and then a paper mailing, in thatorder, can be used if the electronic delivery fails.

The server 108 also has access an image directory that tracks whereimages associated with completed reports are stored. The image directorycan be stored on the server 108 or on a separate device accessible bythe server 108. The image directory can map the unique identifier of animage study (e.g., the accession number) to an identifier of theassociated image viewer 107 through which the image study can beaccessed. Alternatively or in addition, the image directory can map anidentifier of an image repository 106 to the associated image viewer107. In some embodiments, the report source 102 provides an identifierof the associated image viewer 107 or image repository 106 with thecompleted report, which the server 108 can use to create an entry in theimage repository. In other embodiments, the server 108 can be configuredto associate the unique identifier received from a particular reportsource 102 to the same imaging repository 106 and/or image viewer 107.Therefore, in these situations, the report source 102 does not need toprovide this information to the server 108 with a completed report.

The server 108 also creates a link (e.g., a uniform resource locator(“URL”)) that identifies the image study associated with the report. Insome embodiments, the link is based on (e.g., includes) the uniqueidentifier provided by the report source 102. However, in otherembodiments, the link is based on (e.g., includes) a separate uniqueidentifier generated by the routing server 108. For example, the routingserver 108 can be configured to generate a unique identifier for eachreceived report (i.e., for each image study associated with a receivedreport). The generated unique identifier can include a sequential numbergenerated by the server 108, which the server 108 stores with the uniqueidentifier provided by the report source 102. In other embodiments, thegenerated unique identifier includes a combination of portions of theunique identifier provided by the report source 102 (e.g., accessionnumber combined with patient identifier). Also, in some embodiments theserver 108 uses other data relating to the completed report or theassociated image study to establish the unique identifier (i.e., inaddition to any portion of the unique identifier provided by the reportsource 102), such as an identifier of the image viewer 107 through whichthe image study can be accessed.

After creating the link, the server 108 transmits the completed reportand the link to the recipient. In some embodiments, the server 108transmits the completed report and the link as separate files. Forexample, the server 108 can transmit the link as an email message, textfile, etc. Alternatively or in addition, as illustrated in FIG. 1C, theserver can 108 embed the link into the completed report. Thus, it shouldbe understood that the “completed report” transmitted by the server 108as described in the present application can include the report and theassociated link as separate pieces of data (e.g., separate files), thereport with the link embedded therein, or a combination thereof.

Based on the data stored in the recipient directory, the server 108 cantransmit the completed report by faxing or mailing a hard copy of thereport to the recipient. Alternatively or in addition, the server 108can transmit the completed report to the recipient by transmitting thecompleted report to the report destination 104, which can include anemail server, an EMR, a HIS, a cloud storage environment, etc. Forexample, the server 108 can be configured to transmit the completedreport to a network managed by a healthcare provider organization or athird-party organization (e.g., a clinical messaging network). Thenetwork then delivers the completed report to the report destination 104(e.g., an EMR), where the completed report is stored and accessible bythe recipient. When the report destination 104 includes an EMR or otherpatient-information system, the report destination 104 can be configuredto automatically associate the report with any other patient informationalready stored in the report destination 104. It should be understoodthat the network delivering the completed report can be configured tofurther process the report as part of delivering the report to thereport destination 104.

In other embodiments, where email is used to deliver the completedreport (i.e., the report destination 104 includes an email server), theserver 108 can be configured to add the completed report as anattachment to an email message (e.g., a secure email message) sent tothe recipient's email address. The recipient receiving the email canopen the report attached to the email and can store or print the report(e.g., into an EMR, HIS, or other system) as desired. In someembodiments, the email message also includes the link associated withthe completed report.

In some embodiments, the server 108 can be configured to send anotification to a recipient after transmitting a completed report. Forexample, based on information contained in the recipient directory, theserver 108 can send a recipient an electronic message, such as an emailmessage, text message, voice message, etc., that informs the recipientthat the report was transmitted (e.g., faxed, mailed, emailed,transmitted to an EMR, etc.). Alternatively or in addition, the reportdestination 104 can send a notification.

For example, FIG. 4 illustrates a message 400 received by a recipientinforming the recipient that a report was delivered. As noted above, themessage 400 can be generated by the report destination 104 and/or theserver 108. As illustrated in FIG. 4, the message 400 can include a link402 that the recipient can select (e.g., click on) to view the receivedreport (e.g., within the report destination 104). However, in otherembodiments, the report or a portion thereof can be embedded in themessage 400 or included as an attachment. Also, in some embodiments, themessage 400 can include the link associated with the completed report.

FIGS. 5 and 6 illustrate a report 500 accessible by a recipient (e.g.,through clicking the link 402 included in the message 400). Asillustrated in FIG. 6, the link 502 generated by the routing server 108is embedded in the report 500. The recipient can select (e.g., click on)the link 502 to access the image study associated with the report 500.In particular, when the recipient clicks on the embedded link 502, thephysician is directed to the server 108 (e.g., a web page provided bythe server 108 and accessible over the Internet through a browserapplication). As illustrated in FIG. 1C, when the link 402 is selected,the server 108 is passed the unique identifier (i.e., the accessionnumber) associated with the requested image study. The server 108 usesthe unique identifier to identify the image viewer 107 where therequested image study is stored. In particular, the server 108 accessesthe image directory and uses the unique identifier to identify the imageviewer 107 through which the images can be accessed. The server 108 thenprovides the recipient with access to the image viewer 107.

The server 108 can provide access to the image viewer 107 in one or moreways. For example, in one embodiment, as illustrated in FIG. 7, theserver 108 provides access to the image viewer 107 by sending therecipient an address or link (e.g., a URL) identifying the image viewer107. The recipient can use the link to access the image viewer 107,provide credentials (e.g., a username and password) to the image viewer107, provide the unique identifier to the image viewer 107, and (ifauthorized) view one or more images included in the image study throughthe image viewer 107. It should be understood that, in some embodiments,the recipient can communicate with the image viewer 107 over a wired orwireless network, such as the Internet, a local area network, etc.

Alternatively, as illustrated in FIG. 8, the server 108 can provide therecipient with access to the image viewer 107 by automaticallyredirecting the recipient to the image viewer 107. After redirecting therecipient to the image viewer 107, the image viewer 107 can prompt therecipient for credentials and the unique identifier for the requestedimages. The image viewer 107 can then display the requested images tothe recipient if the recipient's credentials are authorized.

Alternatively, as illustrated in FIG. 9, the server 108 can beconfigured to provide the recipient with access to the image viewer 107by automatically redirecting the recipient to the image viewer 107 andautomatically logging the recipient into the image viewer 107. Forexample, in some embodiments, the server 108 can prompt the recipientfor his or her credentials for the image viewer 107 (e.g., a usernameand a password). For example, the server 108 can provide a userinterface 1000 as illustrated in FIG. 10 that includes a “User Name”input mechanism 1002, a “Password” input mechanism 1004, and a “Log In”selection mechanism 1006. Upon receiving the recipient's credentials,the server 108 can pass the credentials to the image viewer 107 andseamlessly log the recipient into the image viewer 107. After beinglogged into the image viewer 107, the recipient can supply the imageviewer 107 with the unique identifier, which the image viewer 107 canuse to identify which image study to display for the recipient. Itshould be understood that in some embodiments, after logging therecipient into the image viewer 107, the server 108 can also beconfigured to provide the image viewer 107 with the unique identifier(as compared to having the recipient provide the identifier to the imageviewer 107).

Alternatively, as illustrated in FIG. 11, the server 108 can beconfigured to provide the recipient with access to the image viewer 107by automatically redirecting the recipient to the image viewer 107 andautomatically logging the recipient into the image viewer 107 withoutprompting the recipient for the credentials. For example, therecipient's credentials provided to the report destination 104 (e.g.,for initially accessing the completed report 500) can be provided to (orstored) by the server 108. Accordingly, the server 108 can use thecredentials to automatically log the recipient into the image viewer107. In this situation, the server 108 can be configured to use therecipient's credentials for the report destination 104 as thecredentials for the image viewer 107 or can be configured to look up therecipient's credentials for the image viewer 107 using the recipient'scredentials for the report destination 104 or other identifyinginformation of the recipient. Accordingly, in these embodiments, thephysician can access the image study using a single sign-on (i.e., onlysigning into the report destination 104). After being logged into theimage viewer 107, the recipient can provide the unique identifier to theimage viewer 107 to access the image study. However, as illustrated inFIG. 11, to continue the seamless nature of this embodiment, the server108 can be configured to automatically provide the image viewer 107 withthe unique identifier before transferring the recipient to the imageviewer 107. Therefore, in this embodiment, the recipient selects thelink 502 and seamlessly views the associated images without beingrequired to provide any intermediary or further input.

It should be understood that in any embodiment where the server 108 logsinto the image viewer 107 on the recipient's behalf, the server 108 cancontinue to communicate with the image viewer 107 on the recipient'sbehalf and forward information from the image viewer 107 to therecipient, including, for example displaying images. In thesesituations, the server 108 acts as an interface between the recipientand the image viewer 107. For example, in some embodiments, therecipient may not have credentials for the image viewer 107, but theserver 108 can have credentials for the image viewer 107, which theserver 108 can use to access the requested image study (e.g., as long asthe server 108 can verify the recipient and the recipient'sauthorization to view the requested image study).

FIG. 12 illustrates a user interface 1200 (e.g., provided by the imageviewer 107 or the server 108) that displays images of the requestedimage study to a recipient. As illustrated in FIG. 12, in someembodiments, the user interface 1200 allows the recipient to takecertain actions on the displayed images including changing imagecharacteristics (e.g., magnification, brightness, contrast, etc.),adding notes or text, locally storing images, etc.

Using the server 108 to initially route the report 500 and embed thelink 502 allows a recipient, such as the ordering physician, tocommunicate with many different report sources 102 and imagerepositories 106 (e.g., different RISs, PACSs, etc.) without requiringdedicated infrastructure (e.g., HL7 interfaces, VPNs, etc.) between theparties. Using the server 108 also allows the location of stored imagesto change without breaking the embedded link 502. For example, if animage repository 106 (e.g., a PACS) is upgraded, the server 108 can bereconfigured to automatically access the upgraded repository 106 forrequested images without needing to provide the recipient with a newlink 502. Similarly, if a PACS becomes available in a cloud storageenvironment, the server 108 can be reconfigured to automatically accessthe cloud environment rather than the PACS even when a user clicks anembedded link 502 generated before images were available through thecloud storage environment. In particular, the server 108 uses the imagedirectory to map requested images to an image repository 106 orassociated image viewer 107. Accordingly, the image directory can beupdated to allow the server 108 to provide access to stored imagesthrough the link 502 even as the stored images change storage locationsor are accessible through different image viewers 107.

In some embodiments, the server 108 is configured to keep logs of routedreports (e.g., tracking successful deliveries, delivery failures, etc.).Therefore, the server 108 can provide a dashboard that allows users(e.g., imaging providers, referring physicians, server administrators,etc.) to track whether a particular report was successfully deliveredand obtain various statistics regarding report status (e.g., sent,confirmed, failed, etc.) and usage of the server 108. For example, theserver 108 can track what reports have been received from report sources102 and what reports have been transmitted to the report destination104. In some embodiments, the server 108 can also be configured toreceive status notifications from the report destination 104 (e.g.,through the network accessing the report destination, such as a clinicalmessaging network) regarding whether the report was successfullydelivered to the report destination 104. In some embodiments, the reportdestination 104 can also provide information to the server 108 regardingwhat reports were accessed or viewed. The server 108 can provide thisinformation or a portion thereof to users to allow users to trackreports through the system 100. Also, in some embodiments, the server108 can provide this information or a portion thereof to the reportsource 102, and the report source 102 can make this informationavailable to users (see FIG. 3).

For example, FIG. 13 illustrates a user interface 1300 provided by theserver 108 and remotely accessible over a network, such as web pageaccessible by a user over the Internet using a browser application. Theinterface 1300 includes current statistics 1302 (e.g., how many reportswere delivered today) and historical statistics 1304 (e.g., how manyreports were delivered for the current month). In some embodiments, theuser interface 1300 also provides notification statistics 1306 regardingthe number of notifications provided by the server 108, which canindicate failures, errors, and timeouts. It should be understood thatthe statistics provided in the user interface 1300 can be tied toauthorizations or roles assigned to the user requesting the statistics.For example, a user associated with a single report source 102 may onlybe able to view statistics through the user interface 1300 regarding theassociated report source 102. However, a user associated with multiplereport sources 102 may be able to view statistics regarding multiplereport sources 102 (e.g., individually or aggregated in one or morecombinations).

In some embodiments, a user can also query the server 108 to track orobtain details regarding one or more reports. For example, FIG. 14illustrates a user interface 1400 provided by the server 108 andremotely accessible over a network, such as a web page accessible by auser over the Internet using a browser application. The user interface1400 allows a user to view details regarding one or more reports handledby the server 108. For example, as illustrated in FIG. 14, a user canuse input mechanisms 1402 included in the interface 1400 to specifyquery parameters, such as a message identifier, an accession number, adate or date range, a status, recipient information, a report source, areport destination, an imaging provider, an imaging provider location,etc. The server 108 uses the query parameters to generate a list 1404 ofmatching reports, which the server 108 displays to the user.Accordingly, a user can use the interface 1400 to obtain detailsregarding a particular report, reports handled during a predeterminedtime period, reports sent to a particular recipient, etc.

Also, in some embodiments, the server 108 provides reportingfunctionality. For example, in some embodiments, the server 108generates and provides reports to users. The reports can include defaultreports and customized reports. For example, as illustrated in FIG. 15,the server 108 can provide a user interface 1500 that displays atimeline report 1502. The timeline report 1502 sequentially identifiesthe interactions between one or more report sources 102 and the server108 over a predetermined period (e.g., the past 24 hours, the past week,the past month, etc.). The server 108 can also provide a usage report.For example, FIG. 16 illustrates a user interface 1600 provided by theserver 108 that allows a user to view a usage report 1602 providingusage statistics (e.g., number of reports sent, number of reportsdelivered, number of failures, etc.) for one or more report sources 102.In some embodiments, usage reports 1602 are used for billing purposes.In some embodiments, the server 108 also provides attestation reports,which can indicate a number of reports that were successfully deliveredto the report destination, a number of reports that were accessed, and,optionally, a number of image sets assessed associated with deliveredreports. Accordingly, the attestation reports can be used to provideinformation regarding a percentage of reports that are providedelectronically and provide electronic access to the correspondingimages. Again, the particular functionality, including the types ofreports, available to a particular user can be based on the user'sauthorizations and/or assigned roles. Also, it should be understood thatthe reports generated by the server 108 can be provided through a userinterface provided by the server 108 and remotely accessible over anetwork, such as a web page accessible by a user over the Internet usinga browser application, or can be directly transmitted to users, such asattachments to an email message or as another electronic ornon-electronic transmission (e.g., faxed, mailed, etc.).

Order Routing

In some embodiments, in addition to or as an alternative to the reportrouting described above, the server 108 can be used to route orders froma physician to the report source 102 (e.g., a RIS) or another systemthat handles procedure and patient scheduling (e.g., a HIS).Accordingly, a physician can place an order through the server 108 toensure that a patient undergoes a recommended procedure and, optionally,uses an imaging provider associated with the physician (e.g., includedin the same network).

For example, as illustrated in FIG. 17, a referring physician canprovide order information to the server 108. In some embodiments, thereferring physician provides order information through a user interfaceprovided by the server 108 that is remotely accessible over a network,such as web page accessible by a user over the Internet using a browserapplication. In addition or as an alternative, the referring physiciancan provide order information to the server 108 directly from an ordersource 1700, such as the referring physician's EMR system.

The server 108 routes received order information (or a portion thereof)to a report source 102 associated with an imaging provider (e.g., a RISor a HIS). The imaging provider processes the order information toschedule the ordered procedure, perform the procedure to obtain an imagestudy, and provide a completed image report based on the image study.Regardless of whether the resulting image report is distributed by theserver 108 as described above, a referring physician can track thestatus of an order placed through the server 108 and, in someembodiments, can receive a completed report for an order and/or accessthe associated image study through the server 108. It should beunderstood that, as used in this section of the present applicationrelating to order routing, a “referring physician” can include thereferring physician (e.g., a patient's primary physician) or a userassociated with the referring physician such as a nurse, an assistant,another physician in the same office as the referring physician, etc.

As noted above, to obtain order information from a referring physician,the server 108 can provide an interface remotely accessible over anetwork, such as a web page accessible by a user over the Internetthrough a browser application. For example, FIG. 18 illustrates a userinterface 1800 that allows a referring physician to enter orderinformation. In some embodiments, each imaging provider can beassociated with their own version of the user interface 1800.Accordingly, a referring physician can receive a link (e.g., a URL) fromeach imaging provider that the referring physician works with (e.g., iswithin the referring physician's healthcare network or otherwise has anexisting relationship with the referring physician). Creating a separateinterface 1800 for each imaging provider allows an imaging provider tocustomize the interface 1800 and also limits the amount of informationavailable to a referring physician (e.g., the referring physician onlysees imaging locations associated with a particular imaging provider,which the referring physician has screened or otherwise is familiar within terms of services and quality). However, in some embodiments, theserver 108 can provide a central interface 1800 that a referringphysician can access to place an order with one of multiple availableimaging providers.

As illustrated in FIG. 18, a referring physician can create a new orderusing the interface 1800 by selecting a “Create Order” selectionmechanism 1802. The interface 1800 then prompts the referring physicianfor order information. The order information can include an ordernumber. For example, a referring physician can optionally specify anorder number for a new order using an “Order Number” input field 1804.The order number can correspond to an order number managed by thereferring physician's order source 1700. For example, in someembodiments, the referring physician places an order within the ordersource 1700, which automatically generates a unique number for theorder. The referring physician can enter this unique number into theinterface 1800 to correlate the order placed through the server 108 withthe order placed through the order source 1700. For example, when areport is received in response to the order, the report can be linkedwith the order placed through the order source 1700. Also, in someembodiments, entering the order number from the order source 1700 intothe interface 1800 can allow the server 108 to automatically pull orderdata from the order source 1700 (e.g., and automatically pre-populateone or more input fields and selection mechanisms provided through theuser interface 1800). In other embodiments, the server 108 can beconfigured to assign a unique order number to each order.

The order information can include patient information. For example, asillustrated in FIG. 18, the referring physician can provide a patient'sname using a “First Name” input field 1806 and a “Last Name” input field1808, a patient's date of birth using a “Date of Birth” input field1810, a patient's gender using a “Gender” selection mechanism 1812, anda patient's contact information using a “Preferred Contact” input field1813, an “Address” input field 1814, a “City” input field 1816, a“State” selection mechanism 1818, and a “Zip Code” input field 1820. Insome embodiments, the patient information also includes a patient'ssocial security number (“SSN”) or other unique identifier. For example,as illustrated in FIG. 18, the referring physician can use a “SSN” inputfield 1822 to provide a patient's SSN. In some embodiments, the userinterface 1800 provides one or more search mechanisms 1823 that allowthe referring physician to search for patient information rather thanentering it manually (e.g., patient information previously enteredthrough the interface 1800 and maintained by the server 108 and/orpatient information managed by the order source 1700 and/or the reportsource 102). For example, if the referring physician entered patientinformation through the interface 1800 for a previous order, thereferring physician may be able to use the search mechanisms 1823 toautomatically populate patient information through the interface 1800.

The order information can also include referring physician information.For example, as illustrated in FIG. 18, the referring physician canprovide a referring physician's name using a “Referring Physician”selection mechanism 1824. In some embodiments, the referring physicianinformation also includes an office of the referring physician (e.g., tokeep orders separate for different offices maintained by the referringphysician).

In addition, the order information can include insurance information forthe patient. For example, as illustrated in FIG. 18, a referringphysician can provide the name of an insurance provider using a“Provider” input field 1830, an insurance group number using a “Group”input field 1832, and an insurance policy number using a “Policy” inputfield 1834. If a patient carries multiple insurance policies, thereferring physician can enter insurance information for each policy.

Optionally, the referring physician can also attach one or more patientdocuments to the order (e.g., using one or more attachment selectionmechanisms 1836). The attachments can include an electronic medicalrecord, previous images, physician notes, or a continuity of caredocument (e.g., in the clinical document architecture (“CDA”)).

As illustrated in FIG. 19, the order information provided through theinterface 1800 can include urgency information. For example, asillustrated in FIG. 19, the user interface 1800 also allows a referringphysician to mark an order as urgent by selecting an “Urgent” selectionmechanism 1840. In some embodiments, after a report is generated for anorder, the imaging provider can also mark an order as urgent regardlessof whether the referring physician initially marked the order as urgent(e.g., by transmitting an urgent identifier to the server 108 with acompleted report).

The order information can also include image procedure information. Forexample, as illustrated in FIG. 19, the user interface 1800 can promptthe referring physician to select a body part being imaged using a “BodyPart” selection mechanism 1842, a position of the body part being imagedusing a “Laterality” selection mechanism 1844, a reason for theprocedure using a “Reason” selection mechanism 1846, a diagnosisassociated with the procedure using a “Diagnosis” selection mechanism1848, and an exam selection using an “Exam” selection mechanism 1850. Itshould be understood that one or more of the selection mechanismsprovided for specifying the imaging procedure being ordered can includeone or more drop-down menu that allow the referring physician to selectan input from a list. The lists can be correlated such that when thereferring physician selects an input from one list, the other lists arecustomized. For example, if the referring physician selects “Back” asthe body part for the imaging procedure, the user interface 1800 can beconfigured to automatically modify the list of selectable exams (e.g.,provided through the “Exam” selection mechanism 1850). Accordingly, theuser interface 1800 can aid the referring physician in selecting theright exam and other imaging procedure details.

As illustrated in FIG. 19, the referring physician can also providenotes associated with the imaging procedure (e.g., using a “Notes” inputfield 1852). In addition, the referring physician can indicate whetherthe imaging provider (e.g., the radiologist) can use a contrast agentfor the imaging procedure at his or her discretion (e.g., using a“Discretion” selection mechanism 1854). Furthermore, as illustrated inFIG. 19, a user can add multiple procedures to an order (e.g., using an“Add Another Procedure” selection mechanism 1856).

In some embodiments, the server 108 provides clinical decision supportfor a new order. For example, as illustrated in FIGS. 20 and 21, after areferring physician specifies an imaging procedure (e.g., an exam) for anew order, the server 108 compares the specified procedure to theassociated patient information (e.g., the reason and/or body partspecified for the procedure and urgency of the procedure) and otherinformation to determine the appropriateness of the order (e.g., basedon one or more rules, such as the American College of Radiology'sselection guidelines). The server 108 then provides a ranking for thespecified procedure based on appropriateness, which is displayed to thereferring physician. For example, as illustrated in FIG. 20, the rankingcan be displayed within an “Exam Ranking” section 1860. In someembodiments, as illustrated in FIGS. 20 and 21, the ranking can becolor-coded. For example, in some embodiments, a ranking can be coloredred to signify “Do Not Proceed,” colored orange to signify “Proceed withCaution,” and colored green to signify “Proceed.” Accordingly, aphysician can use the color-coding to understand whether he or sheshould revise the selected exam and/or other procedure information.Also, in some embodiments (see FIG. 20), a referring physician canselect the displayed ranking (e.g., by hovering over the displayedranking) to access an explanation regarding the ranking. In someembodiments, the ranking can also take into consideration any otherprocedures included in the new order or other orders.

Furthermore, in some embodiments, the server 108 can be configured toautomatically suggest alternative exams (e.g., when the ranking is belowa predetermined value or when other exams exist that have betterrankings). For example, as illustrated in FIG. 20, the user interface1800 can include an “Alternate Exams” selection mechanism 1862, whichcan include a drop-down of available exams. The drop-down of availableexams can include those exams (e.g., applicable for the selected bodypart, laterality, reason, diagnosis, etc.) that have a higher rankingthan the exam currently selected. For example, the server 108 can beconfigured to determine a ranking for each available exam providedthrough the “Exam” selection mechanism 1850 (which, as noted above, canbe customized based on the user's selection of body part, laterality,reason, diagnosis, etc.). The server 108 then populates the drop-downlist for the “Alternate Exams” selection mechanism 1862 with each examhaving a higher ranking than the currently-selected exam. It should beunderstood that, in some embodiments, the server 108 provides theranking only as a suggestion and does not prevent the referringphysician from continuing the order process with the specifiedprocedure.

In some embodiments, the order information also includes destinationinformation that specifies one or more recipients for the image reportultimately generated for the order (e.g., the referring physician, otherspecialists, other physicians treating the same patient, etc.). Forexample, as illustrated in FIGS. 19-21, the user interface 1800 caninclude a “Send Report” input field mechanism 1870. A referringphysician can manually enter destination information (e.g., a recipientname, email address, fax number, EMR system, etc.) using the “SendReport” input mechanism 1870. Alternatively or in addition, a referringphysician can use a search selection mechanism 1871 to locatedestination information (e.g., based on destination information enteredby the referring physician in previous orders, destination informationmaintained by the server 108, destination information maintained by thereport source 102 and/or the order source 1700, or a combinationthereof). In some embodiments, the server 108 can also identify one ormore default destinations, such as the referring physician. The userinterface 1800 can display the default destination and any destinationsselected by the referring physician within a list 1872, which thereferring physician can modify (e.g., delete recipients) as desired.

In some embodiments, the order information also includes imagingprovider information. For example, as illustrated in FIG. 22, the userinterface 1800 can prompt the referring physician to choose an imagingprovider (sometimes referring to as an imaging center) from a list 1882of available providers. As noted above, in some embodiments, the userinterface 1800 can be associated with a specific imaging provider.Accordingly, in these situations, the referring physician does not needto select a specific imaging provider. The imaging provider informationcan also include imaging location information. For example, the userinterface 1800 can include a list 1884 of locations associated with animaging provider. The list 1884 can include address information andother information for each location (e.g., hours, accessibility options,insurance networks, etc.). In some embodiments, the user interface 1800allows the referring physician to sort or filter locations included inthe list 1884. For example, a referring physician can sort or filter theavailable locations by locations previously selected by the referringphysician, by locations within a predetermined distance from thereferring physician or another geographic location, by locationsoffering the imaging exam selected by the referring physician, byinsurance networks, by availability, etc.

As illustrated in FIG. 22, in some embodiments, the user interface 1800can also provide a map 1886 that graphically display a markerrepresenting the geographical location of each location included in thelist 1884 (and, optionally, a marker showing the referring physician'soffice location). To select a particular location, the referringphysician can select a “Select” selection mechanism 1888 associated withthe location.

In some embodiments, after entering order information, the server 108requires that the order be signed by the referring physician. The server108 can require that the order be signed by the actual physician placingthe order. For example, if a referring physician's nurse or assistantenters the order information, the referring physician may be required tosign the order. As illustrated in FIG. 23, a referring physician cansign an order by entering credentials, such as a username and apassword, using one or more “Credentials” input fields 1892 andselecting a “Sign Order” selection mechanism 1894. As illustrated inFIG. 23, the referring physician can provide notes for a signed orderusing a “Notes” input field 1896. Also, in some embodiments, the server108 allows a referring physician to sign a batch of orders needingsignature. For example, a user can select a “Batch Sign” selectionmechanism 1898 provided through the use interface 1800 to view of listof orders needing signatures. The referring physician can then selectone or more of the listed orders for signing with a single signature.

As illustrated in FIG. 17, once an order is signed, the order is routedby the server 108 to a report source 102 associated with the imagingprovider (and location) specified in the order (e.g., a RIS or an HIS).In some embodiments, the report source 102 can be configured to storethe received order as an order entered directly in the report source102. Alternatively, the imaging provider receiving the order can use thereceived order to manually enter the order into the report source 102(e.g., by printing a hard copy and manually entering the data from theprinted copy into the report source 102).

Also, in some embodiments, the server 108 communicates with the reportsource 102 through a gateway. The gateway can be configured to poll theserver 108 for new orders associated with the report source 102, and,when a new order is available on the server 108, the gateway receivesthe order information from the server 108, transforms the orderinformation (e.g., to the health level 7 (“HL7”) standard), andtransfers the transformed order information to the report source 102.The gateway can be used to manage security requirements associated withthe report sourced 102 or to simplify the interaction between the server108 and a report source 102.

After receiving an order through any of the above mechanisms, the reportsource 102 processes the order. In particular, after the order has beenentered into the report source 102 (e.g., automatically or manually),the order is scheduled. For example, the imaging provider can contactthe patient to schedule the ordered procedure (e.g., automatically or bycontacting the patient).

In addition, the report source 102 can process an order by verifying theorder information and making changes to the order information asnecessary. For example, an imaging provider may (e.g., manually orautomatically) identify that a different procedure would be better forthe order. These changes can be provided to the server 108, which canmake the changes known to the referring physician. For example, theserver 108 can generate one or more notifications (e.g., email messages,text messages, etc.) when changes are made to an order, which can besent to the referring physician (and/or other recipients associated withthe order). Alternatively or in addition, a referring physician can benotified of changes the next time he or she accesses the interface 1800provided by the server 108. In some embodiments, when a referringphysician access an order through the interface 1800 that has beenchanged, the interface 1800 marks the changes using highlighting oranother mechanism. The referring physician can review the changes andcan provide feedback (e.g., further changes). Also, in some embodiments,a referring physician can re-sign a change order to approve the changes.When an order is changed (e.g., by any user), the server 108 can beconfigured to save the changed order as a new version and preserve theprevious version (e.g., for auditing purposes and to identify whatchanges have been made).

A referring physician can also use the interface 1800 to track thestatus of a submitted order. For example, as an order is processed, thereport source 102 (or a gateway as described above) can transmit statusinformation regarding the order to the server 108 (see FIG. 17). Theserver 108 makes the status information available to the referringphysician through the interface 1800. For example, FIG. 24 illustratesthe user interface 1800 displaying a list 1900 of orders placed throughthe server 108. A referring physician can use the list 1900 and one ormore sorting/filtering selection mechanisms 1901 to identify what ordersare in progress, what orders are complete (e.g., a report is available),what orders are awaiting signatures, what orders are urgent (e.g.,designated with an icon 1902, such as red flag), what orders areawaiting change approvals, etc. For each listed order, the referringphysician can select a “View Order” selection mechanism 1904 to viewdetails associated with an order.

In some embodiments, a referring physician can also set persistentsorting or filtering for orders tracked through the server 108. Forexample, a referring physician can request that displayed orders befiltered by date, status, etc. and save this setting as persistentfiltering. Thereafter, each time the referring physician accesses theinterface 1800 provided by the server 108, the displayed orders can besorted and filtered according to the saved persistent filtering. Thereferring physician, however, can modify the sorting and filtering asneeded (e.g., without modifying the persistent filtering or by turningoff the persistent filtering).

In some embodiments, the referring physician can configure accesssettings for the interface 1800. For example, the referring physiciancan specify what orders or parts of an order can be viewed and/ormanipulated by the referring physician's assistants or other personnel(e.g., whether assistants can view reports generated for orders and/orthe associated images). Access settings can also be configured to allowa referring physician to see orders placed by other referringphysicians. For example, in some embodiments, the server 108 can alloworders placed by referring physicians in an office to be viewed and/oredited by any physician in the same office (e.g., for back-up purposesif a particular referring physician is unavailable). Other groups ofphysicians can similarly be configured within the server 108 to allowone physician to view and/or edit the orders of another physician.

In some embodiments, a referring physician can also use the interface1800 provided by the server 108 to access reports for completed orders.For example, in some embodiments, the report source 102 transmitscompleted reports to the server 108 (e.g., in addition to locallystoring the reports), and the server 108 forwards the reports asdescribed above. Alternatively or in addition, the server 108 can storea copy of the reports for access by the referring physician through theinterface 1800. For example, as illustrated in FIG. 24, the interface1800 can provide a “View Report” selection mechanism 1910 and/or a “ViewImages” selection mechanism 1912 that a referring physician can selectto view the report and/or images associated with an order. In someembodiments, the report stored by the server 108 can include theembedded link as described above. Also, as the interface 1800 providedby the server 108 can initially prompt a referring physician forcredentials (as part of authorizing access to the interface 1800), theserver 108 can use these credentials to automatically log the referringphysician into an image viewer 107 for accessing images associated witha report provided through the interface 1800 (see FIG. 11).

It should be understood that the server 108 can provide statistics andreporting functionality as described above for report routing and fororder routing. For example, the server 108 can be configured to providestatistics and reports regarding the number of orders transmitted, thenumber of notifications generated for any such orders, timeline reports,usage reports, etc.

Pre-Authorization

In some embodiments, in addition to or as an alternative to the reportrouting and/or the order routing described above, the server 108 isconfigured to manage a pre-authorization process for a submitted order.For example, in some embodiments, when a report source 102 (e.g., a RISor an HIS) associated with an imaging provider receives an order(outside of the server 108), the report source 102 identifies (e.g.,manually or by executing a set of predetermined rules) whether the orderrequires insurance pre-authorization. If pre-authorization is required,the report source 102 can inform the server 108 of the requirement andprovide the server 108 with information regarding the order.

In other embodiments, if an order is submitted through the server 108 asdescribed above, the report source 102 can receive the order, executethe rules, and notify the server 108 of the pre-authorizationrequirement similar to providing status updates for an order asdescribed above. In these situations, the report source 102 may notprovide the server 108 with information regarding the order (e.g.,besides an identifier of the order, such as a unique order number and anindication that pre-authorization is required) since the server 108already has the order information. For orders initially submittedthrough the server 108, the server 108 can use the pre-authorizationinformation received from the report source 102 like any other statusinformation for an order. For example, as illustrated in FIG. 25, theserver 108 can be configured to set a status of an order requiringpre-authorization to “Awaiting Pre-Authorization” or “Pre-AuthorizationIn Progress.”

It should also be understood that in some embodiments, in addition or asan alternative to the report source 102 applying the pre-authorizationrules, the server 108 can be configured to automatically applypre-authorization rules to orders submitted to the server 108 toidentify those orders requiring pre-authorization.

It should also be understood that in some embodiments, the server 108 isconfigured to manage pre-authorization processes for both orderssubmitted to the server 108 and orders submitted outside of the server108. Accordingly, a user can use the server 108 to trackpre-authorization processes for orders within a single user interfaceregardless of how an order was created.

In addition to tracking the status or identifying orders requiringpre-authorization (and providing such information through the userinterface 1800), the server 108 can manage the pre-authorizationprocess. For example, the server 108 can provide an interface remotelyaccessible over a network, such as web page accessible by a user overthe Internet through a browser application. The user interface can allowa user (i.e., a user authorized to perform pre-authorizations) to accessorders requiring pre-authorization and perform pre-authorization tasks.For example, FIG. 26 illustrates a user interface 2600 provided by theserver 108. The user interface 2600 provides a checklist or workflow forcompleting a pre-authorization process (e.g., verifying insurance,verifying patient information, verifying order information, verifyingphysician and imaging center information, and obtaining thepre-authorization). Accordingly, a user performing a pre-authorizationprocess can use the server 108 to identify an order needingpre-authorization, obtain a checklist for completing a pre-authorizationprocess for the order, and track progression through the checklist.

For example, as illustrated in FIG. 26, during the pre-authorizationprocess, a user can enter notes using a “Notes” input field 2601. Itshould be understood that in some embodiments, notes entered by a usercan be associated with a particular task of the pre-authorizationprocess. However, the notes can be combined and displayed within acommon field. It should also be understood that different accesssettings can be assigned to the notes and other input provided to theuser interface 2600 during the pre-authorization process. For example,in some embodiments, only the user performing the pre-authorizationprocess (and, optionally other users authorized to performpre-authorizations) can view and/or edit the input. However, in otherembodiments, individuals authorized to view the order undergoing thepre-authorization process, such as the referring physician and theimaging provider, can view the input. Accordingly, in these embodiments,the referring physician and the imaging provider can view the input totrack the progress of the pre-authorization process being performed foran order.

As illustrated in FIG. 26, the interface 2600 lists a plurality of tasksfor performing a pre-authorization process for a particular order. Eachtask is associated with an icon 2602 that identifies the status of thetask (e.g., uncompleted or completed). Each icon 2602 can change (e.g.,automatically or manually) as a task is completed. Each task is alsoassociated with a “Start” selection mechanism 2604. A user can selectthe “Start” selection mechanism 2604 to view the details or steps of aparticular task and provide associated input (e.g., view data, provideverifications of data, etc.).

For example, FIG. 27 illustrates the user interface 2600 displayingsteps of a pre-authorization task and the information needed to completethe steps. For example, as illustrated in FIG. 27, the interface 2600provides insurance information and at least a portion of the orderinformation to allow a user to contact the patient's insurance companyto obtain a pre-authorization code, which the user enters in a“Pre-authorization Code” input field 2606. The user interface 2600 canalso allow a user to enter other information associated with thepre-authorization code, such as a co-pay amount using a “Co-Pay” inputfield 2608, a deductible amount using a “Deductible” input field 2610, adate range during which the authorization is valid using a start dateselection mechanism 2612 and an end date selection mechanism 2614,coinsurance information using a “Coinsurance” input field 2616, and astatus (e.g., “Authorized”) using a “Status” selection mechanism 2618.

As illustrated in FIG. 27, the user interface 2600 can also provideother information to aid the user in obtaining the authorization codeand related information. For example, the user interface 2600 caninclude a “Payor Rules” selection mechanism 2620 that a user can selectto access rules associated with the patient's insurance coverage.Similarly, the user interface 2600 can include a “View Order” selectionmechanism 2622 that a user can select to access additional detailsregarding the order. Also, in some embodiments, the user interface 2600includes a list 2624 of past procedures. The interface 2600 can also beconfigured to compare a current order to previous orders for the samepatient to automatically identify when a new order is for a procedurethat was previously performed for the patient. If the newly-orderedprocedure is a repeat procedure, the user interface 2600 can alert theuser.

After a user enters the pre-authorization code and related informationinto the user interface 2600, the user can select a “Save” or “Submit”selection mechanism 2640 to save the entered details. Also, after thepre-authorization details are entered, the server 108 can automaticallynotify the report source 102 associated with the order that thepre-authorization process is complete and can, optionally, provide thereport source 102 with the pre-authorization code and/or relatedinformation (e.g., directly or through a gateway as described above). Inthis situation, the report source 102 can process the order as describedabove (e.g., contact the patient to schedule the procedure,automatically schedule the procedure, etc.). In some embodiments,however, the report source 102 can process an order even if apre-authorization process for the order has not been completed.

When a task included in the pre-authorization process is completed, theuser interface 2600 can also automatically update the icon 2602associated with the task (see FIG. 26). In other embodiments, a user canmanually change an icon 2602 (e.g., by selecting or clicking on the icon2602). Also, in some embodiments, the server 108 automatically updatesthe status of the order after the pre-authorization process is complete(e.g., as illustrated in FIG. 25). It should be understood that one ormore of the tasks or one or more of the steps associated with a task canbe automatically performed (e.g., by the server 108 or through athird-party system or service).

Furthermore, in some embodiments, the server 108 provides functionalityfor managing a team of users performing pre-authorizations. For example,as illustrated in FIG. 28, the server 108 can provide a user interface2800 remotely accessible over a network, such as web page accessible bya user over the Internet through a browser application. The userinterface 2800 allows a user (e.g., a manager of a team of usersperforming pre-authorizations) to view a list 2802 of orders needingpre-authorizations. Each order included in the list 2802 can beassociated with a “View Order” selection mechanism 2804 that allows theuser to access details regarding the order. Each order included in thelist 2802 is also associated with an assignment selection mechanism2806. Each assignment selection mechanism 2806 can include a menu (e.g.,a drop-down menu) of available team members for performingpre-authorizations. Accordingly, the team manager can use the assignmentselection mechanism 2806 to assign a particular order to a particularteam member. After an order is assigned to a team member, the teammember can be notified of the order. For example, in some embodiments,when a team member logs into the user interface 2800, the interface 2800notifies the member of his or her assigned orders. Alternatively or inaddition, the server 108 can generate a notification (e.g., an emailmessage, text message, voice message, etc.) that alerts the team memberof the assigned order. In some embodiments, the menu of available teammembers can be automatically customized based on details of theassociated order. For example, if an order is associated with aparticular insurance company, the menu of available team members may befiltered to only include those teams members familiar with the insurancecompany. Similarly, the menu of available team members may be filteredbased on the backlog of each team member (e.g., to aid equaldistribution of assignments). Also, in some embodiments, team memberscan use the assignment selection mechanism 2806 to personally selectorders to process (as compared to being assigned an order by the teammember).

As also illustrated in FIG. 28, the user interface 2800 can provide adashboard 2820. The dashboard 2820 provides information regarding one ormore of the team members performing pre-authorizations. For example, asillustrated in FIG. 28, the dashboard 2820 can include a graphicalrepresentation 2822 of a team member and an indication 2824 of thenumber of orders assigned to the team member. Accordingly, a teammanager and team members can use the dashboard to quickly andefficiently identify the work load of each member. In some embodiments,the user interface 2800 also allows an order to be re-assigned to adifferent team member (e.g., for workload balancing). Thisfunctionality, however, may only be provided to team managers.

It should be understood that the server 108 can provide statistics andreporting functionality as described above for report routing forpre-authorization management. For example, the server 108 can beconfigured to provide statistics and reports regarding the number ofpre-authorization requests received, the number of pre-authorizationprocesses completed, the time required to complete one or morepre-authorization processes, the number of notifications generated forany pre-authorization processes, timeline reports, usage reports, etc.

It should be understood that the server 108 can be configured to providereport routing, order routing, pre-authorization, or any combinationthereof. Also, in some embodiments, when the server 108 is configured toperform both report routing and order routing, a generated report can bedelivered as described above for report routing and be made availablewith a user interface provided by the server 108 as described above fororder routing. Also, it should be understood that functionalitydescribed in the present application as being performed by the server108 can be distributed among multiple servers. Furthermore, thefunctionality described here as being performed by the server 108 can beperformed by the user interfaces provided by the server 108 and viceversa.

Thus, embodiments of the invention provide methods and systems formanaging image orders, reports, and/or pre-authorizations using networkconnections, such as the Internet. Accordingly, the methods and systemsdescribed herein eliminate the need for entities to establish andmaintain direct connections within a dynamic and evolving industry.

Various features and advantages of the invention are set forth in thefollowing claims.

What is claimed is:
 1. A method of managing an image study, the methodcomprising: identifying, with a server, an order for an imagingprocedure requiring insurance pre-authorization; displaying, with theserver, the order to a first user through a user interface remotelyaccessible over a network connection; receiving, with the server, anassignment of the order to a second user from the first user;displaying, with the server, the order to the second user through theuser interface; displaying, with the server, a plurality of tasks forobtaining the insurance pre-authorization for the order to the seconduser through the user interface, wherein one of the plurality of tasksincludes receiving a pre-authorization code for the order; tracking,with the server, completion of each of the plurality of tasks by thesecond user through the user interface; and providing, with the server,information regarding the completion of each of the plurality of tasksto the first user through the user interface.
 2. The method of claim 1,wherein identifying the order requiring insurance pre-authorizationincludes executing, with the server, a plurality of rules against aplurality of orders.
 3. The method of claim 1, wherein identifying theorder requiring insurance pre-authorization includes receiving the orderfrom an imaging provider performing the imaging procedure.
 4. The methodof claim 1, further comprising displaying a number of orders assigned tothe second user to the first user through the user interface.
 5. Themethod of claim 1, further comprising displaying previous imagingprocedures performed for a patient associated with the order within theuser interface.
 6. The method of claim 1, further comprising receivingfrom the first user, through the user interface, a re-assignment of theorder from the second user to a third user.
 7. The method of claim 1,further comprising receiving, through the user interface, notes from thesecond user for at least one of the plurality of tasks and storing thenotes.
 8. The method of claim 7, further comprising displaying to thefirst user, through the user interface, the notes.
 9. The method ofclaim 1, further comprising, prompting the second user, through the userinterface, for the pre-authorization code and automatically, afterreceiving the pre-authorization code from the second user through theuser interface, notifying a report source of pre-authorization of theorder.
 10. The method of claim 1, further comprising displaying to thefirst user, through the user interface, a number of orders assigned tothe second user and a number of orders assigned to a third user.
 11. Asystem for managing an image study, the system comprising: a serverconfigured to communicate with a report source and including a portalproviding access to user interfaces accessible over at least one networkconnection, the server configured to identify an order for an imagingprocedure requiring insurance pre-authorization, display the order to afirst user through the portal, receive an assignment of the order to asecond user from the first user through the portal, display the order tothe second user through the portal, display a plurality of tasks forobtaining the insurance pre-authorization for the order to the seconduser through the portal, wherein one of the plurality of tasks includesreceiving a pre-authorization code, track completion of each of theplurality of tasks by the second user through the portal, and provide,through the portal, information regarding the completion of each of theplurality of tasks to the first user.
 12. The system of claim 11,wherein the server is configured to identify the order requiringinsurance pre-authorization by executing a plurality of rules against aplurality of orders.
 13. The system of claim 11, wherein the server isconfigured to identify the order requiring insurance pre-authorizationby receiving the order from an imaging provider performing the imagingprocedure.
 14. The system of claim 11, wherein the server is furtherconfigured to display to the first user, through the portal, a number oforders assigned to the second user.
 15. The system of claim 11, whereinthe server is further configured to display to the second user, throughthe portal, previous imaging procedures performed for a patientassociated with the order.
 16. The system of claim 11, wherein theserver is further configured to receive a re-assignment from the firstuser, through the portal, re-assigning the order from the second user toa third user.
 17. The system of claim 11, wherein the server is furtherconfigured to receive from the second user, through the portal, notesfor at least one of the plurality of tasks and store the notes.
 18. Thesystem of claim 17, wherein the server is further configured to displayto the first user, through the portal, the notes.
 19. The system ofclaim 11, wherein the server is further configured to prompt the seconduser, through the portal, for the pre-authorization code andautomatically, after receiving the pre-authorization code from thesecond user through the user interface, notify a report source ofpre-authorization of the order.
 20. The system of claim 11, wherein theserver is further configured to display to the first user, through theportal, a number of orders assigned to the second user and a number oforders assigned to a third user.